Community

Do we have to have the US spelling of "licence".

Chris

I agree entirely with your analysis as I too spent a great deal of time dealing with corporate action notifications. However, a digital notary is not the answer as this does not get to the root of the problem. A whole industry has grown up to cleanse and golden copy the data (usually structured theses days either ISO15922 or ISO20022) but has never sorted out the root cause problem.

This is that the Issuers (or rather the PIPS) publish this data as raw text without structure. The problems arise downstream when a myriad of intermediaries such as data providers, custodians and sub-custodians introduce transcription errors when keying the raw data into a structured format. These the get exponentially magnified as each of them sends out notifications to their clients.

The LSE which still accounts for some 70% of corporate action notifications provides its issuers with a template to publish the notice. Why has this template not been amended so that issuer input would produce structured output. Together with Gary, I have been banging on about this for the past decade, but still no action.

The regulators, in the form of the UK Listing Authority, should mandate that every public company must issue all regulatory news in a structured format.

In the US they have grasped this and the DTCC now mandates that all corporate notifications are published in XBRL format (in conjunction with SWIFT and XBRL-US) so the technology is there it just needs the will to do it.

I demonstrated this in action nearly ten years ago and found then, probably as now, that the people who understand the problem and its consequences have little or no clout when it comes to allocating budgets and getting consensus for industry-wide initiatives. Unfortunately, corporate actions come a long way down the pecking order when other more high-profile projects are considered

This is not a cash versus electronic payment argument as most cash is obtained electronically, it is a problem of having a single point of failure - a card. If you had more than one card in your wallet, you would be inconvenienced but not incapable of paying. So, if the new electronic wallets are trying to get us to put all our card details in a single place they are introducing a potential single point of failure. I will always retain multiple methods of payment, whether it be cash or card.

The creation of a federated LEI database that is accessible by all will be a welcome result of this initiative. Initially populating such a database will take some time but is quite achievable given that the national bodies may well be able to link this to existing identifiers issued to registered legal entities. But that is the easy bit.

Maintaining the quality of that data in near to real-time poses a huge problem which, if not addressed, will cause the global financial community to believe that they are correctly reporting counterparty risk because it complies with the LEI database, when in fact the risk is incorrectly stated because the underlying data in the federated LEI database is out of date.

As an example, a global bank headquartered in the US agrees to sell off a division of its business with subsidiaries in multiple jurisdictions and some SPV's in exotic locations. Although there will no doubt be a regulatory announcement that the listed global bank has completed the deal, there will be no exact detail of which legal entities are part of the deal. Until all of the changes to legal ownership are registered in the LEI database, every counterparty who deals with with one of the subsidiaries or SPV's will be incorrectly aggregating their counterparty risk to the wrong ultimate holding company.

The financial intermediaries who are responsible for the actual transfer of legal title need to be required to submit a change record to the LEI database. This would need to be in a structured format that be used as an automated update to the LEI database that would then get synchonised globally across the federation.

How do you identify who should have responsibility for these timely updates and do you enforce this?

A couple of my colleagues in major financial institutions are already being allowed to use their IPhones with an App from Good Technology which apparently creates a secure virtual machine on the hard drive and links in to all of the corporate MS Exchange data.

The key here, like all security issues, is for the recipient to have confidence that information regarding the corporate action event contained in the xbrl file has been published by the organization that claims to be the publisher and that the document is identical to the one that was published and has not been tampered with in any way between publication and receipt.

How can this be achieved? I think that what is necessary is a trusted third-party to act as a Certificate Authority (CA) that issues digital certificates to Issuers to encrypt the files and publishes the public key that enables the files to be read and authenticated.

In this scenario, all of the Issuers would have to register with the CA. Gary, if you read my comments on your previous blog you will see that I am suggesting that the likes of the DTCC and the FSA are the most likely candidates for holding a registry of all XBRL Issuers. I cannot see these organisations wanting to become CA's (although I have long held the belief that they should) so the answer maybe for an existing CA to issue a special root CA to DTCC or FSA or any other organisation that operates a Registry and these organizations can in turn use the same root certificate.

I don't think that there are many candidates for the registry operator role other than those that I have mentioned. The hardest part will be for them to agree on a common course of action.

One other problem arises. What happens to the XBRL file once it has been received. A file may contain hundreds of tagged items, the very nature of an xml file is that it is a text file and can be edited. How do you handle or authenticate that a piece of tagged data within an XBRL file has not been changed once it arrives inside your organization? I don't have the answer to that one.

There may yet be a very simple solution for the smaller buy-side firms that want to consume Corporate Action Events published in XBRL. The whole idea of splitting the message data away from the network supplier has always scared the life out of SWIFT and other data vendors that aggregate and distribute data. The value that they add currently is that they clean the data, or produce the 'golden copy', removing ambiguities and finding errors. Then they distribute it in a format that can be imported directly into user's systems.

If the data is published by the Issuer, it is the 'golden copy' so no data cleansing is required. If the Issuer has to publish Corporate Action Events in XBRL format then why could they not also publish the XBRL file on their Investor Relations website and enable RSS feed subscription. Buy-side firms could then subscribe to the RSS feeds they require. Simple converter tools would then pump the RSS feed into a back-end portfolio system.

That would have the effect of disintermediating the middle-man that is adding no value. Isn't that what the internet has been promising to deliver all this time?

In fact Gary, having read your latest post, this is directly related. The value added service would be the discovery of all the RSS feeds from all the Issuers by way of some form of international registry.

I think that such a registry should be held by the competent authority to whom the Issuers are reporting and then be made freely available for lookup by the general public (well maybe a small subscription to cover costs!). In the US this would be the DTCC or SEC and in the UK, the FSA as UK Listing Authority. The registries held by each competent authority should be created in an agreed common format and be federated between each of them so each hold a copy of the full registry.

The technology for this already exists as an international standard ebXML Registry.

Liz

You state that 'There is also the lack of widespread knowledge concerning XBRL and XML outside of the US.' I would like to inform you that one of the most respected XBRL technology companies that is heavily involved with all of many of the XBRL activities in the US is actually based in Oxford, once called DecisionSoft they have recently changed their name to CoreFiling.

HMRC were very early adopters of XBRL and lead the world in their electronic filing for Corporation Tax Returns (XBRL), also developed in collaboration with CoreFiling. Companies House also have adopted XBRL for the filing of company accounts. The lack of awareness of XBRL within the UK Financial Services sector is mainly due to the ill-fated and lamentable decision by the FSA some years ago to overturn a published policy decision and ditch XBRL for regulatory reporting. This was for short-sighted and internal political reasons - they now find themselves out on a limb. XBRL has become the reporting technology of choice for the vast majority of European securities and banking regulators.

As the FSA are now also the UK Listing Authority they would be responsible for introducing any mandate for UK Issuers to publish their corporate actions in XBRL. Is there anyone in the FSA with the foresight and balls to admit that they took a wrong turn on XBRL and now adopt it so that UK corporate action data can be distributed alongside that of the DTCC.